This section describes how to compile the generated code for C# and VB.NET, which references to add and how to use it in your own projects.
 Note: |
If you're using LLBLGen Pro with WCF RIA services, this section applies to the generated code project(s) and the domain service project, not for the Silverlight application, as the Silverlight application doesn't use the generated entity classes so you don't need to reference any of the runtime framework assemblies in the Silverlight application of your WCF RIA services solution. |
The easiest way to compile the generated code is to load the generated Visual Studio.NET project file(s) into Visual Studio.NET or another IDE which can read these files and compile the project. The generated Visual Studio.NET projects by default have the proper references set up. If you're upgrading to a newer version of LLBLGen Pro, it's recommended to check whether your project indeed references the correct runtime libraries, as VS.NET sometimes may point to previous versions if they're still installed on your system. After you have generated the code and checked whether the right references are available in your VS.NET project, you can compile the code into a working assembly. This assembly can then be referenced from your business logic project and other projects which want to use the generated functionality.
Below a brief description of each runtime library assembly is given and when it should be referenced.
| Note: |
Starting with LLBLGen Pro v4.0, the SD.LLBLGen.Pro.LinqSupportClasses.NET35 and SD.LLBLGen.Pro.QuerySpec assemblies have been merged into the SD.LLBLGen.Pro.ORMSupportClasses assembly so there's no need anymore to reference these. If you migrated your project to v4.0 or higher, and it still references the LinqSupportClasses and/or QuerySpec assemblies, please remove these references. |
LLBLGen Pro ships with two versions of this assembly, one general assembly compiled against .NET 3.5, and one compiled against .NET 4.5 with additional async/await code. Both assemblies are called SD.LLBLGen.Pro.ORMSupportClasses.dll. The .NET 4.5 one is located in the CompiledRuntimeLibraries\NET4.5 folder and contains all code of the regular, .NET 3.5 build. The ORMSupportClasses assembly is referenced by all generated code projects, and you also need to reference it from any project which uses the classes from the generated code. This assembly contains the LinqSupportClasses and QuerySpec code as well.
When you generate code for .NET 3.5 or .NET 4.0, the normal, non-async version is referenced, and you should reference that one from you own code as well. When you generate code for .NET 4.5, the async version from the .NET 4.5 folder is referenced, and you should reference that version in your code as well.
LLBLGen Pro ships with a specific ORM Support Classes assembly for web development: SD.LLBLGen.Pro.ORMSupportClasses.Web.dll. This assembly contains the DataSourceControls for two-way databinding in webforms. It also contains the designers for these controls; adding the controls from this assembly to the VS.NET toolbox allows you to drag/drop DataSourceControls onto webforms. When your web application uses the LLBLGen Pro datasource controls, you have to reference this assembly from the Web project.
All SQL is generated by a Dynamic Query Engine or DQE in short. These engines are database specific and each supported database has its own assembly: SD.LLBLGen.Pro.DQE.yourdatabase.dll where yourDatabase is for example SqlServer, Oracle, Firebird etc. LLBLGen Pro ships with one version of this assembly per database, which is usable for all .NET versions supported: .NET 3.5 or higher. The DQE assembly has to be referenced in the generated code project for SelfServicing and the database specific project of Adapter.
MySql specific: The DQE shipped with LLBLGen Pro for MySql can be
used with MySqlDirect provider from CoreLab or from DevArt.
LLBLGen Pro ships with full support for WCF Ria Services, a framework by Microsoft to create rich silverlight applications with a service based server tier. To create a service for WCF Ria Services using the generated code, you have to reference this assembly in your project which implements your DomainService class. .NET 4.0 or higher specific.
LLBLGen Pro ships with full support for WCF Data Services, the OData implementing framework by Microsoft. To create a WCF Data Service service using the generated code, you have to reference this assembly in your project which implements your Data Service class. .NET 4.0 or higher specific. The ODataSupportClasses are compiled against the WCF Data Services Server assembly available from nuget.
LLBLGen Pro uses the DbProviderFactory system. This means that you don't need to reference the ADO.NET provider assembly in your generated code. In general the ADO.NET provider installation programs also install a definition of the ADO.NET provider's DbProviderFactory in the machine.config file of the .NET CLR used. There are two exceptions: Firebird and Postgresql. Please see the sections below for these specific databases and to setup the DbProviderFactory declaration for your own application.
For firebird, using Firebird client v2.x, please add to the .config file of your application the following lines:
<system.data> <DbProviderFactories> <!-- Firebird --> <add name="Firebird Client Data Provider" invariant="FirebirdSql.Data.FirebirdClient" description=".Net Framework Data Provider for Firebird" type="FirebirdSql.Data.FirebirdClient.FirebirdClientFactory, FirebirdSql.Data.FirebirdClient, Version=2.7.0.0, Culture=neutral, PublicKeyToken=3750abcc3150b00c" /> </DbProviderFactories> </system.data>
NOTE: Be sure the version of the ADO.NET provider you use for Firebird
matches the version specified. In the example above the version is
'2.7.0.0'. Don't change the invariant string, that string has to be 'FirebirdSql.Data.FirebirdClient'.
Users of the newer Firebird Client v3.x ADO.NET provider don't have to add the abovelines, as the Firebird Client installer already installed the proper configuration in machine.config.
For PostgreSql using Npgsql, please add to the .config file of your application the following lines:
<system.data> <DbProviderFactories> <!-- PostgreSql --> <add name="PostgreSql Client Data Provider" invariant="Npgsql" description=".Net Framework Data Provider for PostgreSql" type="Npgsql.NpgsqlFactory, Npgsql, Version=2.0.4.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7" /> </DbProviderFactories> </system.data>
NOTE: Be sure the version of the ADO.NET provider you use for Npgsql
matches the version specified. In the example above the version is
'2.0.4.0'. Don't change the invariant string, that string has to be 'Npgsql'.
When compilation of the generated code was successful, you can reference the compiled dll from your project, which holds the code using the generated classes, or reference the generated code projects directly. Furthermore, you have to copy the generated app.config file to the executable project which references (indirectly perhaps via another assembly) the generated code. If you are developing a web project, you have to copy the appSettings tag and its contents of generated app.config file to the web.config file of your application, inside the configuration tag. This will make sure the generated code will be able to read the connection string.
A .config file (app.config or web.config) can have a separate connection strings section in which you can store the connection string as well. This is supported by LLBLGen Pro. A connection string specified in the connection strings section in the config file is read first. If a connection string with the name specified in the generated code is found there, that connection string is used. If it's not found, the appSettings section is consulted.
// C# string version = SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Version + "." + SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Build;
' VB.NET Dim version As String = SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Version & "." & _ SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Build